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Abstract 

Floating point computation presents a number of problems for for- 
mal verification. Should one treat the actual details of floating point 
operations, or accept them as imprecisely defined? or should one 
ignore roundoff error altogether, and behave as if floating point op- 
erations are perfectly accurate? There is the further problem that a 
numerical algorithm usually only approximately computes some math- 
ematical function, and we often do not know just how good the ap- 
proximation is, even in the absence of round-off error. 

ORA has developed a theory of asymptotic correctness which al- 
lows one to verify floating point software with a minimum entangle- 
ment in these problems. We describe this theory and its implemen- 
tation in the Ariel C verification system, also developed at ORA. We 
illustrate the theory using a simple program which finds a zero of a 
given function by bisection. 
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Difficulties 


• Machine real arithmetic does not have nice 
mathematical properties 

• Doesn’t match ideal arithmetic (overflow, round- 
off, underflow) 

• Programs don’t satisfy the specification we’d 
like them to 


Odyssey Research Associates, Inc. 



Asymptotic Correctness 

• Specify “ideal behavior” of the program (e.g. 
“program computes the square root of its in- 
put”) 

• Verify that if program is run on a sequence of 
machines converging to perfect accuracy, then 
program’s behavior converges to ideal behav- 
ior 
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Advantages of the Asymptotic Approach 

• Machine real arithmetic can be specified loosely 

• Specifications can be written in terms of ideal 
behavior 

• Verification does not require roundoff error anal- 
ysis 

• Verifies logical correctness — absence of “bugs” 
from inaccuracy of machine arithmetic that 
are not related to error magnitude. 
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Nonstandard analysis 


RC*R 

Standard part map 
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rounds off a finite nonstandard real to an infinitely close stan- 
dard real. 
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Nonstandard Analysis 

• Asymptotic approach can be formalized natu- 
rally in nonstandard analysis using infinitesi- 
mals 

• Primitive operations are assumed to return 
values which are infinitely close to the ideal 
values when the arguments and ideal answers 
are finite 

• Programs are specified to have behaviors in- 
finitely close to ideal behavior when inputs are 
finite 
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Finding Roots of a Continuous Function 

• f incLzero searchs for a root of a user-supplied 
function F by bisection. 

• At each iteration, it tests to see if the values 
of F at the left endpoint and the midpoint 
are of opposite sign, and changes one of the 
endpoints to the midpoint so as to keep a root 
between the two endpoints. 

• The program terminates when it finds a root 
or when it reachs a user-supplied bound on 
the number of iterations. 


Odyssey Research Associates, Inc, 


float f ind.zero (leftO .rightO .maxit) 
float leftO, rightO; 
int maxit; 

{ 

float left .right .center; 
float cval.lvalO.rvalO; 
int numit; 

numit = 0; 

lvalO = F(leftO) ; 
rvalO ■ F(rightO) ; 

left = leftO; 

right “ rightO; 

center * (left + right)/2.0; 

cval * F (center); 

while (cval != 0.0 && numit < maxit) { 
if (lvalO * cval < 0) 
right = center; 

else 

left = center; 

center = (left + right)/2.0; 
cval = F(center); 
lvalO = F(left) ; 
numit = numit + 1 ; 

> 

return (center) ; 

> 
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Specification of fincLzero 

IF F is continuous and find_zero is started up 
with 

• leftO and rightO not “large”; 

• maxit “large”; 

• F'(leftO) and i^rightO) of opposite sign 

THEN f ind_zero terminates normally (i.e. with- 
out an exception) and the value output is “close 
to” some zero of F. 
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Attempted Verification 

• Proof of termination is easy. 

• Proof that termination is normal is a bit harder. 
Must prove that no overflow happens. To prove 
this, must prove that the values of the end- 
points stay in some range of numbers which 
are not “large” . 
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How would we prove that the program returns an 
approximation to a root? 

• Prove when the program terminates, the end- 
points are “close”. This follows from the fact 
that the program halves the interval a “large” 
number of times. 

• Prove there’s always a root between the end- 
points. This should follow from the way the 
program decides whether to move the left end- 
point or the right. Prom this we’d get center 
“close to” a root. 

Unfortunately, it’s not true that there’s always 
a root between the endpoints. 
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The Bug 

• In the test statement, can have lvalO and 
cval of opposite sign, but have the product 
underflow to 0. This causes the program to 
move the wrong endpoint. 

• Tests bear out this bug. 
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Possible Fixes 


Several ways to fix this bug 
• Change test to 

(lvalO < 0 && cval >= 0) II 
(lvalO >= 0 && cval < 0) 


Change test so instead of always testing left 
endpoint against midpoint, it always tests he 
endpoint with the larger value of F against th 

Ttodoesn’t necessarily keep a root between 
the endpoints, but it delivers an approxima- 
tion to a root anyway. 
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Ariel 


• Verification system for subset of C including 
real arithmetic and some UNIX system calls. 

• Implements nonstandard formalization of the 
asymptotic approach. 
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Semantic Verification 

• Ariel verifies programs by generating a de- 
scription of the program’s denotation in a higliei- 
order language (the Clio metalanguage) 

• Specifications are statements about the deno- 
tation in the Clio metalanguage 

• Verification is a proof of the specification di- 
rectly from the description of the denotation 
in Clio theorem prover 

• Specifications can be any statement about the 
program’s denotation which can be expressed 
in the Clio, including termination 
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C Semantics 


• A “run” of the program is modeled as a se- 
quence of events 

• Events are: 

- the event of going into a certain state 

- terminating and returning a value 

- terminating and returning no value 

- raising an exception 

- an “unknown” event 

• The semantics of the program is expressed as a 
collection of axioms saying which sequences of 
events can happen in the course of executing 
the program. 
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Sample Verifications 

• ZBRENT — a program which finds zeros of a 
continuous function by bisection 

• SWAP — a very simple program to swap the 
contents of 2 locations which contains a sur- 
prising bug 

• HOSTILE BOOSTER — a suite of programs, 
developed by Applied Technology Associates 
for SDIO, that estimate hostile booster trajec- 
tories. This verification is currently in progress. 

• SECURE DEVICE DRIVER — specification 
and verification of security for an Ethernet de- 
vice driver. Currently in progress. 
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